Hi Ray,
Not sure why this is happening. The only thing I can think of is when talking to the libraries an app often "Locks" the Server. This can happen by doing a WaitToken/ReleaseToken or internally with a WriteLineReadLine for example. Could you be in the middle of communicating with the Server when your app terminates?
TK
| Group: DynoMotion |
Message: 2890 |
From: himykabibble |
Date: 1/2/2012 |
| Subject: Re: KMotion_dotNet Error Handlind |
Tom,
It is possible it's in one of the 100mSec updates. I'll try disabling the timer before closing the app, and see if it goes away. That's a reasonable explanation, and would explain why it doesn't happen all the time. Thanks!
Regards,
Ray L.
--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
> Â
> Not sure why this is happening. The only thing I can think of is when talking to the libraries an app often "Locks" the Server. This can happen by doing a WaitToken/ReleaseToken or internally with a WriteLineReadLine for example. Could you be in the middle of communicating with the Server when your app terminates?
> Â
> TK
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, January 2, 2012 8:48 AM
> Subject: [DynoMotion] Re: KMotion_dotNet Error Handlind
>
>
> Â
> Another problem I'm having - I sometimes open KMotion while my app is open, so I can monitor the board state. But, frequently, when I exit my app, KMotion crashes, after complaining it lost communication with the server. Is there a way around this?
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> >
> > So show much can I get away with.... I have a number of GUI elements - DROs, indicator LEDs, etc. that need to be kept updated, and their states can change due to user interaction (via the GUI, dedicated control panel switches, or the pendant) or through G-code operations. The only reasonable way I could see to do this is with timer interrupts that check the current state, and update the GUI as needed. I'm currently doing this every 100mSec. Is this going to be a problem?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> > >
> > > Hello Ray,
> > >
> > >
> > >
> > > I agree with you and that is why there was a lot of discussion about it. In
> > > the end I think it boils down to minimizing USB traffic.
> > >
> > >
> > >
> > > If an application is polling for display/state update and the dll is also
> > > polling for connection then we are risking clogging the USB channel,
> > > especially if there are a lot of motion segments being pushed to the
> > > controller.
> > >
> > >
> > >
> > > Callbacks as I described earlier to eliminate or supplement the pop-ups
> > > would be nice and Tom has received the request before.
> > >
> > >
> > >
> > > -Brad Murry
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> > > Behalf Of himykabibble
> > > Sent: Sunday, January 01, 2012 11:33 PM
> > > To: DynoMotion@yahoogroups.com
> > > Subject: [DynoMotion] Re: KMotion_dotNet Error Handlind
> > >
> > >
> > >
> > >
> > >
> > > Brad,
> > >
> > > OK, I can do that easily, since I already have a 100mSec timer to sync up
> > > display objects. Thanks. So I also need to wrap each access with a if
> > > (Connected) {}, to get rid of the excess error dialogs? Still seems to me it
> > > would be useful for the underlying code to keep track, and only issue the
> > > error dialog once for each disconnect, no? It seems inconsistent to require
> > > the app to track the connected state, but then have the library throwing
> > > error dialogs.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> > > Brad Murry <bradodarb@> wrote:
> > > >
> > > > Hello Ray,
> > > >
> > > >
> > > >
> > > > There was much discussion on this matter and it was decided in the end
> > > > for the calling application to handle connect/disconnect/reconnect
> > > > situations.
> > > >
> > > > The primary reasoning behind this is that connectivity may be more
> > > critical
> > > > in some applications than others and each may need to handle these
> > > scenarios
> > > > in their own way.
> > > >
> > > >
> > > >
> > > > There are recommended mechanisms to cleanly determine whether a connection
> > > > exists, and the KM_Controller.Connected property implements them in very
> > > > much the same way as KMotionCNC.
> > > >
> > > >
> > > >
> > > > It is probably best to have a background thread to check this property(no
> > > > less than 100ms between polling for most applications) and on this thread
> > > > you can route connect/disconnect/re-connect logic appropriately.
> > > >
> > > >
> > > >
> > > > -Brad Murry
> > > >
> > > >
> > > >
> > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> > > On
> > > > Behalf Of himykabibble
> > > > Sent: Sunday, January 01, 2012 8:18 PM
> > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > > Subject: [DynoMotion] KMotion_dotNet Error Handlind
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Brad,
> > > >
> > > > What is the correct way to handle unexpected disconnects and re-connects?
> > > My
> > > > C# app initializes the board, defines I/Os, axes, etc. But if not board is
> > > > present, this results in a large number of error dialogs. Seems to me
> > > what's
> > > > needed is an Event that is called on connect or disconnect, so the app can
> > > > handle transitions gracefully. Is there a simple way to deal with this
> > > that
> > > > I'm not seeing?
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > >
> >
> |
|
| Group: DynoMotion |
Message: 2893 |
From: Brad Murry |
Date: 1/2/2012 |
| Subject: Re: KMotion_dotNet Error Handlind |
A good place to do that would be by overriding your form’s OnClosing:: protected override void OnClosing(CancelEventArgs e) { base.OnClosing(e); } And maybe even double checking in OnClosed() I use the WPF equivalents of these in MM and it seems to work OK. -Brad From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of himykabibble
Sent: Monday, January 02, 2012 6:20 PM
To: DynoMotion@yahoogroups.com
Subject: [DynoMotion] Re: KMotion_dotNet Error Handlind Tom,
It is possible it's in one of the 100mSec updates. I'll try disabling the timer before closing the app, and see if it goes away. That's a reasonable explanation, and would explain why it doesn't happen all the time. Thanks!
Regards,
Ray L.
--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Ray,
> Â
> Not sure why this is happening. The only thing I can think of is when talking to the libraries an app often "Locks" the Server. This can happen by doing a WaitToken/ReleaseToken or internally with a WriteLineReadLine for example. Could you be in the middle of communicating with the Server when your app terminates?
> Â
> TK
>
> From: himykabibble <jagboy@...>
> To: DynoMotion@yahoogroups.com
> Sent: Monday, January 2, 2012 8:48 AM
> Subject: [DynoMotion] Re: KMotion_dotNet Error Handlind
>
>
> Â
> Another problem I'm having - I sometimes open KMotion while my app is open, so I can monitor the board state. But, frequently, when I exit my app, KMotion crashes, after complaining it lost communication with the server. Is there a way around this?
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@> wrote:
> >
> > So show much can I get away with.... I have a number of GUI elements - DROs, indicator LEDs, etc. that need to be kept updated, and their states can change due to user interaction (via the GUI, dedicated control panel switches, or the pendant) or through G-code operations. The only reasonable way I could see to do this is with timer interrupts that check the current state, and update the GUI as needed. I'm currently doing this every 100mSec. Is this going to be a problem?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> > >
> > > Hello Ray,
> > >
> > >
> > >
> > > I agree with you and that is why there was a lot of discussion about it. In
> > > the end I think it boils down to minimizing USB traffic.
> > >
> > >
> > >
> > > If an application is polling for display/state update and the dll is also
> > > polling for connection then we are risking clogging the USB channel,
> > > especially if there are a lot of motion segments being pushed to the
> > > controller.
> > >
> > >
> > >
> > > Callbacks as I described earlier to eliminate or supplement the pop-ups
> > > would be nice and Tom has received the request before.
> > >
> > >
> > >
> > > -Brad Murry
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> > > Behalf Of himykabibble
> > > Sent: Sunday, January 01, 2012 11:33 PM
> > > To: DynoMotion@yahoogroups.com
> > > Subject: [DynoMotion] Re: KMotion_dotNet Error Handlind
> > >
> > >
> > >
> > >
> > >
> > > Brad,
> > >
> > > OK, I can do that easily, since I already have a 100mSec timer to sync up
> > > display objects. Thanks. So I also need to wrap each access with a if
> > > (Connected) {}, to get rid of the excess error dialogs? Still seems to me it
> > > would be useful for the underlying code to keep track, and only issue the
> > > error dialog once for each disconnect, no? It seems inconsistent to require
> > > the app to track the connected state, but then have the library throwing
> > > error dialogs.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> > > Brad Murry <bradodarb@> wrote:
> > > >
> > > > Hello Ray,
> > > >
> > > >
> > > >
> > > > There was much discussion on this matter and it was decided in the end
> > > > for the calling application to handle connect/disconnect/reconnect
> > > > situations.
> > > >
> > > > The primary reasoning behind this is that connectivity may be more
> > > critical
> > > > in some applications than others and each may need to handle these
> > > scenarios
> > > > in their own way.
> > > >
> > > >
> > > >
> > > > There are recommended mechanisms to cleanly determine whether a connection
> > > > exists, and the KM_Controller.Connected property implements them in very
> > > > much the same way as KMotionCNC.
> > > >
> > > >
> > > >
> > > > It is probably best to have a background thread to check this property(no
> > > > less than 100ms between polling for most applications) and on this thread
> > > > you can route connect/disconnect/re-connect logic appropriately.
> > > >
> > > >
> > > >
> > > > -Brad Murry
> > > >
> > > >
> > > >
> > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> > > On
> > > > Behalf Of himykabibble
> > > > Sent: Sunday, January 01, 2012 8:18 PM
> > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > > Subject: [DynoMotion] KMotion_dotNet Error Handlind
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Brad,
> > > >
> > > > What is the correct way to handle unexpected disconnects and re-connects?
> > > My
> > > > C# app initializes the board, defines I/Os, axes, etc. But if not board is
> > > > present, this results in a large number of error dialogs. Seems to me
> > > what's
> > > > needed is an Event that is called on connect or disconnect, so the app can
> > > > handle transitions gracefully. Is there a simple way to deal with this
> > > that
> > > > I'm not seeing?
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > >
> >
>
|
|
| Group: DynoMotion |
Message: 2894 |
From: himykabibble |
Date: 1/2/2012 |
| Subject: Re: KMotion_dotNet Error Handlind |
I think that may have fixed it. We'll see how it goes. Thanks!
Regards,
Ray L.
--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> A good place to do that would be by overriding your form's OnClosing::
>
>
>
> protected override void OnClosing(CancelEventArgs e)
>
> {
>
> base.OnClosing(e);
>
> }
>
>
>
> And maybe even double checking in OnClosed()
>
>
>
>
>
> I use the WPF equivalents of these in MM and it seems to work OK.
>
>
>
> -Brad
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of himykabibble
> Sent: Monday, January 02, 2012 6:20 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: KMotion_dotNet Error Handlind
>
>
>
>
>
> Tom,
>
> It is possible it's in one of the 100mSec updates. I'll try disabling the
> timer before closing the app, and see if it goes away. That's a reasonable
> explanation, and would explain why it doesn't happen all the time. Thanks!
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> > Â
> > Not sure why this is happening. The only thing I can think of is when
> talking to the libraries an app often "Locks" the Server. This can happen
> by doing a WaitToken/ReleaseToken or internally with a WriteLineReadLine for
> example. Could you be in the middle of communicating with the Server when
> your app terminates?
> > Â
> > TK
> >
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > Sent: Monday, January 2, 2012 8:48 AM
> > Subject: [DynoMotion] Re: KMotion_dotNet Error Handlind
> >
> >
> > Â
> > Another problem I'm having - I sometimes open KMotion while my app is
> open, so I can monitor the board state. But, frequently, when I exit my app,
> KMotion crashes, after complaining it lost communication with the server. Is
> there a way around this?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> "himykabibble" <jagboy@> wrote:
> > >
> > > So show much can I get away with.... I have a number of GUI elements -
> DROs, indicator LEDs, etc. that need to be kept updated, and their states
> can change due to user interaction (via the GUI, dedicated control panel
> switches, or the pendant) or through G-code operations. The only reasonable
> way I could see to do this is with timer interrupts that check the current
> state, and update the GUI as needed. I'm currently doing this every 100mSec.
> Is this going to be a problem?
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> , Brad Murry <bradodarb@> wrote:
> > > >
> > > > Hello Ray,
> > > >
> > > >
> > > >
> > > > I agree with you and that is why there was a lot of discussion about
> it. In
> > > > the end I think it boils down to minimizing USB traffic.
> > > >
> > > >
> > > >
> > > > If an application is polling for display/state update and the dll is
> also
> > > > polling for connection then we are risking clogging the USB channel,
> > > > especially if there are a lot of motion segments being pushed to the
> > > > controller.
> > > >
> > > >
> > > >
> > > > Callbacks as I described earlier to eliminate or supplement the
> pop-ups
> > > > would be nice and Tom has received the request before.
> > > >
> > > >
> > > >
> > > > -Brad Murry
> > > >
> > > >
> > > >
> > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> On
> > > > Behalf Of himykabibble
> > > > Sent: Sunday, January 01, 2012 11:33 PM
> > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > > Subject: [DynoMotion] Re: KMotion_dotNet Error Handlind
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Brad,
> > > >
> > > > OK, I can do that easily, since I already have a 100mSec timer to sync
> up
> > > > display objects. Thanks. So I also need to wrap each access with a if
> > > > (Connected) {}, to get rid of the excess error dialogs? Still seems to
> me it
> > > > would be useful for the underlying code to keep track, and only issue
> the
> > > > error dialog once for each disconnect, no? It seems inconsistent to
> require
> > > > the app to track the connected state, but then have the library
> throwing
> > > > error dialogs.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> ,
> > > > Brad Murry <bradodarb@> wrote:
> > > > >
> > > > > Hello Ray,
> > > > >
> > > > >
> > > > >
> > > > > There was much discussion on this matter and it was decided in the
> end
> > > > > for the calling application to handle connect/disconnect/reconnect
> > > > > situations.
> > > > >
> > > > > The primary reasoning behind this is that connectivity may be more
> > > > critical
> > > > > in some applications than others and each may need to handle these
> > > > scenarios
> > > > > in their own way.
> > > > >
> > > > >
> > > > >
> > > > > There are recommended mechanisms to cleanly determine whether a
> connection
> > > > > exists, and the KM_Controller.Connected property implements them in
> very
> > > > > much the same way as KMotionCNC.
> > > > >
> > > > >
> > > > >
> > > > > It is probably best to have a background thread to check this
> property(no
> > > > > less than 100ms between polling for most applications) and on this
> thread
> > > > > you can route connect/disconnect/re-connect logic appropriately.
> > > > >
> > > > >
> > > > >
> > > > > -Brad Murry
> > > > >
> > > > >
> > > > >
> > > > > From: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > > [mailto:DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> ]
> > > > On
> > > > > Behalf Of himykabibble
> > > > > Sent: Sunday, January 01, 2012 8:18 PM
> > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > > > Subject: [DynoMotion] KMotion_dotNet Error Handlind
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Brad,
> > > > >
> > > > > What is the correct way to handle unexpected disconnects and
> re-connects?
> > > > My
> > > > > C# app initializes the board, defines I/Os, axes, etc. But if not
> board is
> > > > > present, this results in a large number of error dialogs. Seems to
> me
> > > > what's
> > > > > needed is an Event that is called on connect or disconnect, so the
> app can
> > > > > handle transitions gracefully. Is there a simple way to deal with
> this
> > > > that
> > > > > I'm not seeing?
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > >
> > >
> >
> |
|
| Group: DynoMotion |
Message: 2895 |
From: himykabibble |
Date: 1/2/2012 |
| Subject: Re: KMotion_dotNet Error Handlind |
Brad,
BTW - Is there anything special I should do with the Controller object before closing, or will it automatically clean up after itself?
Regards,
Ray L.
--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> A good place to do that would be by overriding your form's OnClosing::
>
>
>
> protected override void OnClosing(CancelEventArgs e)
>
> {
>
> base.OnClosing(e);
>
> }
>
>
>
> And maybe even double checking in OnClosed()
>
>
>
>
>
> I use the WPF equivalents of these in MM and it seems to work OK.
>
>
>
> -Brad
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of himykabibble
> Sent: Monday, January 02, 2012 6:20 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: KMotion_dotNet Error Handlind
>
>
>
>
>
> Tom,
>
> It is possible it's in one of the 100mSec updates. I'll try disabling the
> timer before closing the app, and see if it goes away. That's a reasonable
> explanation, and would explain why it doesn't happen all the time. Thanks!
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> Tom Kerekes <tk@> wrote:
> >
> > Hi Ray,
> > Â
> > Not sure why this is happening. The only thing I can think of is when
> talking to the libraries an app often "Locks" the Server. This can happen
> by doing a WaitToken/ReleaseToken or internally with a WriteLineReadLine for
> example. Could you be in the middle of communicating with the Server when
> your app terminates?
> > Â
> > TK
> >
> > From: himykabibble <jagboy@>
> > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > Sent: Monday, January 2, 2012 8:48 AM
> > Subject: [DynoMotion] Re: KMotion_dotNet Error Handlind
> >
> >
> > Â
> > Another problem I'm having - I sometimes open KMotion while my app is
> open, so I can monitor the board state. But, frequently, when I exit my app,
> KMotion crashes, after complaining it lost communication with the server. Is
> there a way around this?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> "himykabibble" <jagboy@> wrote:
> > >
> > > So show much can I get away with.... I have a number of GUI elements -
> DROs, indicator LEDs, etc. that need to be kept updated, and their states
> can change due to user interaction (via the GUI, dedicated control panel
> switches, or the pendant) or through G-code operations. The only reasonable
> way I could see to do this is with timer interrupts that check the current
> state, and update the GUI as needed. I'm currently doing this every 100mSec.
> Is this going to be a problem?
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> , Brad Murry <bradodarb@> wrote:
> > > >
> > > > Hello Ray,
> > > >
> > > >
> > > >
> > > > I agree with you and that is why there was a lot of discussion about
> it. In
> > > > the end I think it boils down to minimizing USB traffic.
> > > >
> > > >
> > > >
> > > > If an application is polling for display/state update and the dll is
> also
> > > > polling for connection then we are risking clogging the USB channel,
> > > > especially if there are a lot of motion segments being pushed to the
> > > > controller.
> > > >
> > > >
> > > >
> > > > Callbacks as I described earlier to eliminate or supplement the
> pop-ups
> > > > would be nice and Tom has received the request before.
> > > >
> > > >
> > > >
> > > > -Brad Murry
> > > >
> > > >
> > > >
> > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> On
> > > > Behalf Of himykabibble
> > > > Sent: Sunday, January 01, 2012 11:33 PM
> > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > > Subject: [DynoMotion] Re: KMotion_dotNet Error Handlind
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Brad,
> > > >
> > > > OK, I can do that easily, since I already have a 100mSec timer to sync
> up
> > > > display objects. Thanks. So I also need to wrap each access with a if
> > > > (Connected) {}, to get rid of the excess error dialogs? Still seems to
> me it
> > > > would be useful for the underlying code to keep track, and only issue
> the
> > > > error dialog once for each disconnect, no? It seems inconsistent to
> require
> > > > the app to track the connected state, but then have the library
> throwing
> > > > error dialogs.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> ,
> > > > Brad Murry <bradodarb@> wrote:
> > > > >
> > > > > Hello Ray,
> > > > >
> > > > >
> > > > >
> > > > > There was much discussion on this matter and it was decided in the
> end
> > > > > for the calling application to handle connect/disconnect/reconnect
> > > > > situations.
> > > > >
> > > > > The primary reasoning behind this is that connectivity may be more
> > > > critical
> > > > > in some applications than others and each may need to handle these
> > > > scenarios
> > > > > in their own way.
> > > > >
> > > > >
> > > > >
> > > > > There are recommended mechanisms to cleanly determine whether a
> connection
> > > > > exists, and the KM_Controller.Connected property implements them in
> very
> > > > > much the same way as KMotionCNC.
> > > > >
> > > > >
> > > > >
> > > > > It is probably best to have a background thread to check this
> property(no
> > > > > less than 100ms between polling for most applications) and on this
> thread
> > > > > you can route connect/disconnect/re-connect logic appropriately.
> > > > >
> > > > >
> > > > >
> > > > > -Brad Murry
> > > > >
> > > > >
> > > > >
> > > > > From: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > > [mailto:DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> ]
> > > > On
> > > > > Behalf Of himykabibble
> > > > > Sent: Sunday, January 01, 2012 8:18 PM
> > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > > > Subject: [DynoMotion] KMotion_dotNet Error Handlind
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Brad,
> > > > >
> > > > > What is the correct way to handle unexpected disconnects and
> re-connects?
> > > > My
> > > > > C# app initializes the board, defines I/Os, axes, etc. But if not
> board is
> > > > > present, this results in a large number of error dialogs. Seems to
> me
> > > > what's
> > > > > needed is an Event that is called on connect or disconnect, so the
> app can
> > > > > handle transitions gracefully. Is there a simple way to deal with
> this
> > > > that
> > > > > I'm not seeing?
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > >
> > >
> >
> |
|
| Group: DynoMotion |
Message: 2900 |
From: bradodarb |
Date: 1/2/2012 |
| Subject: Re: KMotion_dotNet Error Handlind |
Hello Ray,
I would call
KM_Controller.Dispose();
-Brad Murry
--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Brad,
>
> BTW - Is there anything special I should do with the Controller object before closing, or will it automatically clean up after itself?
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> >
> > A good place to do that would be by overriding your form's OnClosing::
> >
> >
> >
> > protected override void OnClosing(CancelEventArgs e)
> >
> > {
> >
> > base.OnClosing(e);
> >
> > }
> >
> >
> >
> > And maybe even double checking in OnClosed()
> >
> >
> >
> >
> >
> > I use the WPF equivalents of these in MM and it seems to work OK.
> >
> >
> >
> > -Brad
> >
> >
> >
> > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> > Behalf Of himykabibble
> > Sent: Monday, January 02, 2012 6:20 PM
> > To: DynoMotion@yahoogroups.com
> > Subject: [DynoMotion] Re: KMotion_dotNet Error Handlind
> >
> >
> >
> >
> >
> > Tom,
> >
> > It is possible it's in one of the 100mSec updates. I'll try disabling the
> > timer before closing the app, and see if it goes away. That's a reasonable
> > explanation, and would explain why it doesn't happen all the time. Thanks!
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> > Tom Kerekes <tk@> wrote:
> > >
> > > Hi Ray,
> > > Â
> > > Not sure why this is happening. The only thing I can think of is when
> > talking to the libraries an app often "Locks" the Server. This can happen
> > by doing a WaitToken/ReleaseToken or internally with a WriteLineReadLine for
> > example. Could you be in the middle of communicating with the Server when
> > your app terminates?
> > > Â
> > > TK
> > >
> > > From: himykabibble <jagboy@>
> > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > Sent: Monday, January 2, 2012 8:48 AM
> > > Subject: [DynoMotion] Re: KMotion_dotNet Error Handlind
> > >
> > >
> > > Â
> > > Another problem I'm having - I sometimes open KMotion while my app is
> > open, so I can monitor the board state. But, frequently, when I exit my app,
> > KMotion crashes, after complaining it lost communication with the server. Is
> > there a way around this?
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> > "himykabibble" <jagboy@> wrote:
> > > >
> > > > So show much can I get away with.... I have a number of GUI elements -
> > DROs, indicator LEDs, etc. that need to be kept updated, and their states
> > can change due to user interaction (via the GUI, dedicated control panel
> > switches, or the pendant) or through G-code operations. The only reasonable
> > way I could see to do this is with timer interrupts that check the current
> > state, and update the GUI as needed. I'm currently doing this every 100mSec.
> > Is this going to be a problem?
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > , Brad Murry <bradodarb@> wrote:
> > > > >
> > > > > Hello Ray,
> > > > >
> > > > >
> > > > >
> > > > > I agree with you and that is why there was a lot of discussion about
> > it. In
> > > > > the end I think it boils down to minimizing USB traffic.
> > > > >
> > > > >
> > > > >
> > > > > If an application is polling for display/state update and the dll is
> > also
> > > > > polling for connection then we are risking clogging the USB channel,
> > > > > especially if there are a lot of motion segments being pushed to the
> > > > > controller.
> > > > >
> > > > >
> > > > >
> > > > > Callbacks as I described earlier to eliminate or supplement the
> > pop-ups
> > > > > would be nice and Tom has received the request before.
> > > > >
> > > > >
> > > > >
> > > > > -Brad Murry
> > > > >
> > > > >
> > > > >
> > > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> > On
> > > > > Behalf Of himykabibble
> > > > > Sent: Sunday, January 01, 2012 11:33 PM
> > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > > > Subject: [DynoMotion] Re: KMotion_dotNet Error Handlind
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Brad,
> > > > >
> > > > > OK, I can do that easily, since I already have a 100mSec timer to sync
> > up
> > > > > display objects. Thanks. So I also need to wrap each access with a if
> > > > > (Connected) {}, to get rid of the excess error dialogs? Still seems to
> > me it
> > > > > would be useful for the underlying code to keep track, and only issue
> > the
> > > > > error dialog once for each disconnect, no? It seems inconsistent to
> > require
> > > > > the app to track the connected state, but then have the library
> > throwing
> > > > > error dialogs.
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > ,
> > > > > Brad Murry <bradodarb@> wrote:
> > > > > >
> > > > > > Hello Ray,
> > > > > >
> > > > > >
> > > > > >
> > > > > > There was much discussion on this matter and it was decided in the
> > end
> > > > > > for the calling application to handle connect/disconnect/reconnect
> > > > > > situations.
> > > > > >
> > > > > > The primary reasoning behind this is that connectivity may be more
> > > > > critical
> > > > > > in some applications than others and each may need to handle these
> > > > > scenarios
> > > > > > in their own way.
> > > > > >
> > > > > >
> > > > > >
> > > > > > There are recommended mechanisms to cleanly determine whether a
> > connection
> > > > > > exists, and the KM_Controller.Connected property implements them in
> > very
> > > > > > much the same way as KMotionCNC.
> > > > > >
> > > > > >
> > > > > >
> > > > > > It is probably best to have a background thread to check this
> > property(no
> > > > > > less than 100ms between polling for most applications) and on this
> > thread
> > > > > > you can route connect/disconnect/re-connect logic appropriately.
> > > > > >
> > > > > >
> > > > > >
> > > > > > -Brad Murry
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > > > [mailto:DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > ]
> > > > > On
> > > > > > Behalf Of himykabibble
> > > > > > Sent: Sunday, January 01, 2012 8:18 PM
> > > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > Subject: [DynoMotion] KMotion_dotNet Error Handlind
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Brad,
> > > > > >
> > > > > > What is the correct way to handle unexpected disconnects and
> > re-connects?
> > > > > My
> > > > > > C# app initializes the board, defines I/Os, axes, etc. But if not
> > board is
> > > > > > present, this results in a large number of error dialogs. Seems to
> > me
> > > > > what's
> > > > > > needed is an Event that is called on connect or disconnect, so the
> > app can
> > > > > > handle transitions gracefully. Is there a simple way to deal with
> > this
> > > > > that
> > > > > > I'm not seeing?
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > >
> > > >
> > >
> >
> |
|
| |
